As the level of technology increases, the options for communications have become more varied. For example, in the last 30 years in the telecommunications industry, personal communications have evolved from a home having a single rotary dial telephone, to a home having multiple telephones, cable and/or fiber optic lines that accommodate both voice and data. Additionally cellular phones and Wi-Fi have added a mobile element to communications. Similarly, in the entertainment industry, 30 years ago there was only one format for television and this format was transmitted over the air and received via antennas located at homes. This has evolved into both different standards of picture quality such as, standard definition TV (SDTV), enhanced definition TV (EDTV) and high definition TV (HDTV), and more systems for delivery of these different television display formats, such as cable and satellite. Additionally, services have grown to become overlapping between these two industries. As these systems continue to evolve in both industries, the service offerings will continue to merge and new services can be expected to be available for a consumer. Also these services will be based on the technical capability to process and output more information, for example as seen in the improvements in the picture quality of programs viewed on televisions, and therefore it is expected that service delivery requirements will continue to rely on more bandwidth being available throughout the network including the “last mile” to the end user.
Another related technology that impacts both the communications and entertainment industries is the Internet. The physical structure of the Internet and associated communication streams have also evolved to handle an increased flow of data. Servers have more memory than ever before, communications links exist that have a higher bandwidth than in the past, processors are faster and more capable and protocols exist to take advantage of these elements. As consumers' usage of the Internet grows, service companies have turned to the Internet (and other Internet Protocol (IP) networks) as a mechanism for providing traditional services. These multimedia services include Internet Protocol television (IPTV, referring to systems or services that deliver television programs over a network using IP data packets), Internet radio, video on demand (VOD), Voice over IP (VoIP), and other web related services received singly or bundled together.
IPTV is thus the delivery of programming of TV video streams encoded as a series of IP packets. IPTV can deliver either live TV or stored video (Video-on-Demand). IPTV service may also be bundled with other IP services, including VoIP and high-speed Internet access. In traditional television delivery, all programming (the TV programs) is broadcast simultaneously, over the air or over cable. The available program signals flow downstream and the viewer selects which program he wants to watch by changing the channel. IPTV, by contrast, typically sends only one program at a time. Content remains on the service provider's network and only the program the customer selects is sent to the home. When a viewer changes the channel, a new media stream is transmitted from the provider's server directly to the viewer. Like cable TV, IPTV requires a Set-Top Box (STB). IPTV primarily uses multicasting (a method in which information can be sent to multiple computers/terminals when these computers/terminals join an IP multicast address to which the selected content is being sent) with Internet Group Management Protocol (IGMP) used for live television broadcasts control and Real Time Streaming Protocol (RTSP) control for on-demand programs. Compatible video compression standards include H.264, Windows Media Video 9 and VC1 (Video Codec 1), DivX (a digital video codec created by DivX Networks, Inc.), and XviD (a video codec library following the MPEG-4 standard), and the MPEG-2 (Moving Pictures Expert Group) and MPEG-4. Also, in IPTV, Quality of Service (QoS) of the IPTV contents is guaranteed. As such, new content should be delivered to a requesting viewer (or admitted in the transit and access networks) only if it does not affect content being currently delivered to other users through the above networks.
Reference is now made to FIG. 1 (Prior Art), which shows a simplified network diagram of an exemplary IPTV system 8 for delivering IPTV channels to an end user's terminal. In FIG. 1, a TV 10 is connected to an STB 12. In certain implementation, the combination of an STB 12 functionality combined with a display 10 is referred to as an IPTV Terminal Function (ITF) 13, which is the user's terminal. The ITF 13 is in communication with an access node 14 which in turn is connected with an IP Network 16. The access node 14 may be any type of node which could be used to connect STB 12 to an IP network 16 such as for example a Digital Subscriber Line Access Multiplexer (DSLAM). The IP Network 16 is in communication with one or more IPTV media server(s) 18, which contain(s) the IPTV media content that an end user desires to view upon TV 10. Furthermore, an IPTV content manager 17 functions to find, on behalf of the user, the most appropriate media server 18 (among multiple media servers, not shown) from where the selected media content can be delivered. The media server 18 delivers the IPTV channels containing streaming video in the desired format, e.g., MPEG 2 or MPEG-4, to an end user, where the content is displayed upon TV 10. Media stream control is performed via RTSP sessions 21 established between the media server 18 and the IPTV content manager 17 on one side, and between the IPTV control manager 17 and the ITF 13 on the other side, while the actual media stream is delivered via the media path 23 directly from the media server 18 to the ITF 13. It will be understood that there could be more intervening nodes between the ITF 13 and the media server 18 than those shown in the simplified system of FIG. 1.
In the exemplary IPTV system 8, the content delivery network is typically distributed, i.e. there are multiple media servers 18 (only one is shown for simplicity purposes). This is desirable so that the most closely located media server 18 can be selected to serve a user that desires to access a specific content. As such, a request for watching media content is typically sent from the ITF 13 to the content manager 17, where the later takes on the responsibility of locating the appropriate media server 18 to service the user. Following that, the ITF 13 can start communicating with the content manager 17, to start the streaming of the desired media content. Hence, all RTSP control traffic coming from the ITF 13 is proxied through the content manager 17 to the selected media server 18, while the actual media content is delivered directly from the media server 18 to the ITF 13.
Reference is now made to FIG. 2 (Prior Art) that shows a typical IPTV implementation in an IMS-based (IP Multimedia Subsystem) network 200. In the IMS-based IPTV system, the architecture described previously in relation to FIG. 1 is still valid, and as such there is a need to cope with it, which poses additional challenges. Within the IMS based architecture, an IMS session (also called herein a Session Initiation Protocol (SIP) session) is typically used to set up a unicast session for admission control purposes between an ITF 213, the IMS core network 214, the IPTV control server, 270 and the content manager 270. For this purpose, all these nodes typically support SIP-based communications. The IMS core network 214 typically comprises multiple CSCFs (Call State Control Functions) and other nodes according to the current IMS specifications. The function of the IPTV control server 270 is to coordinate IPTV sessions that need to be established for the provision of IPTV services, perform service access, and generate charging data. The content manager 270 acts, as also briefly described hereinbefore, to control the media servers and acts as a proxy between the ITF and the media server. Finally, FIG. 2 shows an IPTV Media Server 280 (only one is shown for simplicity purposes), which functions to store media content to be streamed to ITFs. In FIG. 2, in order to provide IPTV service to the ITF 213, first, a SIP session 222 is established between the ITF 213, via the IMS core 214 and the IPTV control server 270 and up to the content manager 270. RTSP media stream control can thus be performed between the ITF 213 and the content manager 270 and further with the media server 280 that streams the desired IPTV content toward the ITF 213. Delivery of the media content of interest is performed via a media delivery path 230 established directly between the media server 280 and the ITF 213.
One of the currently proposed approaches within the course of setting up an IMS session for IPTV servicing, is for the content manager 270 to set up the RTSP control session 210, and in such a case the SIP 200 OK sent in response to the SIP INVITE message that initiated the IMS session needs to transport not only the content manager 270 address but also the identifier of the new RTSP session. This allows the content manager to maintain the correlation between the SIP session being used and the RTPS session, which is required for session management purposes and for correlating the charging information generated from the different nodes. Following that, the RTSP session established between the content manager 270 and the ITF 213, the later can start the stream control since it has the RTSP identifier. This option has the advantage that the content manager 270 can maintain an association between the existing SIP session and RTSP session, which ensures that no illegal ITFs can start up illegal RTSP sessions, since ITFs are only allowed to do media stream control (Play, Fast Forward, Stop, etc). On the other hand, this option has the disadvantage that it cannot be used with many existing RTSP stacks where the session setup is an integral part of the stack, i.e. where the ITFs cannot do stream control unless they themselves initiated the creation of the RTSP session. Hence, for many legacy RTSP stacks that are present in ITFs, this option does not work.
As such, there is a need to find another approach that can retain the advantages offered by the IMS-based IPTV architecture, while still allowing legacy RTSP stacks to be used.
Although it does not disclose the teachings of the present invention, the co-pending, co-invented and co-owned U.S. patent application Ser. No. 11/615,506, entitled “A Method of Correlating a Media Session to a Signalling Session” bears some relation with the field of the invention. In this patent application, there is disclosed a user terminal that uses SIP to establish an RTSP media session with a media content server. An application server, which establishes the RTSP media session, links the RTSP media session to the corresponding SIP session. Once the RTSP session is set up and linked to the SIP session, the media content server streams the media content to the user terminal. While this application relates to the field of IPTV, its teaching is limited to a SIP-RTSP sessions correlation performed at the application server level, and thus stops short of disclosing the present invention.
Accordingly, it should be readily appreciated that in order to overcome the deficiencies and shortcomings of the existing solutions, it would be advantageous to have a solution that can retain the advantages offered by the IMS-based IPTV architecture, while still allowing legacy RTSP stacks to be used. The present invention provides such a method and system.